[Previous] [Next] [Index] [Thread]

Re: User Auth.

Content-Transfer-Encoding=8bit
X-Date Tue Mar 26 22:29:34 GMT 1996
X-Mailer: ELM [version 2.4 PL22]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 9101      

In a previous mail , Nathan Neulinger wrote :
 > 
 > At 8:38 PM 3/26/96, S.W. Cheung wrote:
 > >Dear All,
 > >
 > >I got a question about User Auth.  How can I force or allow my users to
 > >"logout" without quitting the client?
 > 
 > Unfortunately, all the browsers seem to have the buttheaderd notion that
 > you'd never want to do this... Makes them completely unsuitable for a
 > shared lab environment.

	Where did you get that idea that the "browsers have the notion ..." ?
This has absolutly nothing to do with any browser.
	Before making any statement of that sort, check the documentation !
	The browsers are there to try to display HTML coded files, and to follow
the http protocol, which does NOT provide for this feature alltogether.
	Excerpt from the last internet draft version (7) on the http 1.0 protocol :

| The HTTP protocol is based on a request/response paradigm.
| A client establishes a connection with a server and sends a request to the
| server in the form of a request method, URI, and protocol version, followed
| by a MIME-like message containing request modifiers, client information, and
| possible body content.The server responds with a status line, including
| the message's protocol version and a success or error code, followed by a
| MIME-like message containing server information, entity metainformation, and
| possible body content.

---text deleted

| Except for experimental applications, current practice requires that the
| connection be established by the client prior to each request and closed by
| by the server after sending the response.

---lot of text deleted

| The HTTP protocol does not restrict applications to this simple
| challenge-response mechanism for access
| authentication. Additional mechanisms may be used, such as encryption at the
| transport level or via message
| encapsulation, and with additional header fields specifying authentication
| information. However, these
| additional mechanisms are not defined by this specification. 

End of excerpt

	The protocol is stateless, ie the client sends a request and gets an answer
(usually some text) from the server. Hence the server does not know anymore
about the request, all is already over and therefore the server cannot force a
"logout", since there is no connection anymore.
	For the protection of documents, the http1.0 protocol catters for a "basic
authentification" .

	Then the client has just a file to display, and again, there is NO
provision in html to say that this file should not be visible after a certain
period (this would mean that the file is automatically deleted from disk or
memory, hence this would be rather difficult to implement both safely and
surely).

The only provided clue about some "time life" of the document is an
"Expire" response header in the initial answer from the http server, but this
does not mean that a browser SHOULD disgard the document once it has expired,
this is only meant to be used by caching mechanisms.

Excerpt of http protocol:
| The Expires field cannot be used to force a user agent to refresh its display
| or reload a resource; its semantics
| apply only to caching mechanisms, and such mechanisms need only check a
| resource's expiration status when a
| new request for that resource is initiated. 
End of excerpt

	When you say "unsuitable for a shared lab environment", this is true, but a
telnet session has the same weakness, reading your mail as well: if you use a
workstation, PC, mac whatever to do something, and this is personnal and should
not be read by other people, then it is usually not at the application level
that you block further access, but at the machine level itself (although, it
would be nice to be able to selectively block individual applications).

	
 > 
 > I've suggested a "Unauthenticate"  menu option to netscape many times, but
 > it's not like they ever listen to users.

	Well, netscape may have *millions* of copies of its browser around, and I
would be quite surprised that they would just modify it to suit any particular
demand of any particular user, for that they would get contradicting demands,
and they anyway must follow the standards (even if admittedly they tamper a
little bit with them).
	Even if netscape was implementing your request, there would still be tens
of other browsers around which would not.
Get real!
 > 
 > -- Nathan
 > 
 > ------------------------------------------------------------
 > Nathan Neulinger                  Univ. of Missouri - Rolla
 > EMail: nneul@umr.edu                  Computing Services
 > WWW: http://www.umr.edu/~nneul      SysAdmin: rollanet.org
 > 
 > 

	To summarize, and to give the beginning of an answer to the original
question there is no proper way to force users to "logout" without quitting
the client, for the reason that users are not "logged in" in a first instance.
But there is some hope ...

	As your question is far to be precise, I will try to guess what you mean.

	If what you mean is that you want the user to enter a passwd for each
protected document, you have then to define a different access control for each
document, with a different user ID each time. This is a very heavy solution,
and request. I suppose this is not exactly what you want.

	If what you mean is that when a user has accessed some passwd protected
document, you want the client not to be able to access other passwd
protected documents after a certain time, then there are some possibilities
through CGI scripts, cookies etc.

1-) You could serve the protected documents with forms. The initial form would
be accessible only through a passwd protection scheme, and would include a
hidden field with a cookie. Any subsequent call of a protected document would
be made through that form and the cookie tested against a validity criteria.
Example:

Client request: GET /protect/secret.htm passwd "fred"
server answers:	echoes <FORM ACTION="get_protected_doc">
	<INPUT TYPE="HIDDEN" VALUE="ufgdsgfsg3478743287jd">
	list of available documents:
			URL with URLENCODED requests, built on the fly when echoing the
form
						or
			<SELECT> <OPTION secret_document_1>
			<OPTION secret_document_2>
			</SELECT>

secret_document_1 and secret_document_2, would then be generated on the fly by
your cgi from original files accessible only by the server (off my head, I am
not sure that if a cgi answers by a "Location", the real URL of the "location"
is visible by the client, so test before doing an print "Location", otherwise,
merely copy the content of location on stdout).
The cookie would be generated at the first call, and then any subsequent
request would test that the cookie is not too old.
This is for the documents served through the form, but with that scheme,
nothing prevents to call the initial form again and get a fresh cookie, you so
need to catter for the case where the form is called again.

PS: Netscape has a cookie scheme with version 1 of its browser ( I suppose this
is still valid with versions 2), and I do not have the pointer at hand, but by
browsing home.netscape.com, you will find the relevant doc. The flaw will be
that it will not be a portable solution, but if you and your users use only
netscape, then this could be another solution.

2-) You could use a CGI script to ask for passwd (<INPUT TYPE="passwd">) for
each protected document and then have your preferred passwd program check it
against the passwd file, but think twice about all possible flaws (example
if the script can check an indefinite number of time for passwd validity, then
you just leave the door wide open for someone to try all combinations for
cracking passwds etc).

3-) You could use a cgi script to launch a child server which would then
serve your documents within the protection scope, hence with an initial
identification. The child server would then be killed after a few
seconds/minutes/hours. That way, new access to the protected documents after
the server has been killed would be by calling the CGI again, hence starting a
new child server which would not have the "memory" of the first one, ie it
would again ask for identification before serving new documents.
	Maybe you could even have  config file built on the fly for the child
server, with only one user-ID allowed and few documents in the document root,
but then catter for firing off several child servers for so many users you may
have at once (and chose a port at random).

	None of these solutions is really very nice and fool proof (they certainly
have security flaws if implemented that way), they would just make a reasonable
attempt at protecting documents against unattended browsers sessions used by
attempt at protecting documents against unattended browsers sessions used by
different users.

	These are just thoughts, and I have NOT tried any of my proposals and may
have missed some important points (again, think to all security implications,
as these solutions may in fact be worse than the initial problem).

Cheers

--
 Philippe Parmentier	 E-mail : P.Parmentier@ecmwf.int
 Snail : ECMWF, Shinfield Park, Reading, Berkshire RG2 9AX, U.K.
Follow-Ups: References: